The present invention relates generally to data networking and, more specifically, to providing delay bound and prioritized packet dropping for MLPP (Multilevel Precedence and Preemption) applications.
The Defense Information Systems Agency (DISA) of the United States Department of Defense, with its contractors, has proposed a service architecture for military (NATO and related agencies) telephone systems. It is called Assured Service, and is defined in two documents: Pierce, et al. “Architecture for Assured Service Capabilities in Voice over IP”, Internet Draft, Internet Engineering Task Force, Jun. 2003, and Pierce, et al. “Requirements for Assured Service Capabilities in Voice over IP”, Internet Draft, Internet Engineering Task Force, Jun. 2003. The Assured Service environment provides voice calls with different levels of precedence. In the event of traffic congestion, mission critical calls will be unaffected while calls of lower level precedence may experience reduced quality.
In overview, the requirement is to support calls of multiple precedence levels. In the absence of congestion, all calls have the same QoS requirements, typically expressed in terms of a bound on queuing delay. However, in the case of contention, when it becomes impossible to satisfy the delay bound for all packets, the requirement is to drop packets of lower preemption (precedence) calls before packets of higher preemption. All the packets which are not dropped must satisfy the specified delay bound for their precedence level.
Several datapath mechanisms have been proposed to satisfy these requirements. One such method is known as MLEF PHB (Multi-Level Expedited Forwarding Per Hop Behavior). The conceptual idea of MLEF PHB is to use a priority queue supplemented with preferential dropping mechanisms (via thresholds, policers, or other suitable mechanisms). The different thresholds intend to facilitate dropping lower precedence packets before the higher precedence packets. One difficulty with MLEF is finding a suitable trade-off between sufficient threshold spacing across all levels to ensure appropriate differentiation across precedence levels (irrespective of packet arrival order) and short enough overall queue size to ensure sufficiently tight delay and jitter bounds. Tuning the thresholds is a daunting task with no clear guidance available at this point.
Another approach is to utilize coupled policers (CP), which build upon the simple token bucket policer by allowing tokens to be shared among different token buckets. However, if multiple classes draw tokens from a common bucket, the resulting behavior depends on the arrival order and may introduce undesirable delays.
A drawback with all of the data-path mechanisms described above is that in the case of congestion, while these methods discriminate among precedence levels with respect to dropping packets, they do not discriminate among calls of the same precedence level. This issue is described in Baker, et al., “MLEF Without Capacity Admission Does Not Satisfy MLPP Requirements,” Internet Draft, Internet Engineering Task Force, February 2004. Baker et al. describe how Call Admission Control (CAC) procedures are also necessary to achieve the desired Assured Service capabilities. In particular, CAC ensures that, during contention within one level of priority, the system does not end up degrading the quality of service of all the calls at that priority so that no effective communication can actually happen at that priority. Rather, in case of contention, CAC can reject the excessive calls which are beyond the current system capacity to make sure that all the calls within the system capacity experience satisfactory quality of service allowing effective communication at that priority.
It has been found that the well-known RSVP protocol can be used to provide such CAC procedures in combination with certain other mechanisms to fully support the Assured Service Capabilities using EF (Expedited Forwarding) PHB (per hop behavior) in the data path. See Baker, et al. “Implementing MLPP for Voice and Video in the Internet Protocol Suite,” Internet Draft, Internet Engineering Task Force, February 2004. The CAC procedures operated by the control plane avoid contention by data packets under normal (non-transient conditions). Some loss could potentially occur, however, in some special circumstances such as due to routing transients or to variable rate beat frequencies. In particular, CAC cannot deal with transient congestion resulting from below-peak rate reservations, or from transient state resulting from network failures, which are frequent occurrences in typical DISA environments. Thus, even in the presence of CAC, an additional mechanism is desired to address transient congestion.
There is, therefore, a need for a method and system that can be used to meet delay bound and prioritized dropping requirements in environments where CAC is not used or in combination with CAC if strict QoS requirements need to be adhered to under transient conditions.